前情提要

昨天我們學會了用 YAML 檔來部署 Pod，也拆解了 Kubernetes YAML 檔的四個必備欄位。透過聲明式配置，我們獲得了 可重現性、版本控制、團隊協作和自動化部署 等優勢。但在上一篇的結尾我提到：如果應用程式需要高可用性，單靠一個 Pod 是不夠的。

想像一下這些情境：

• Pod 掛了，使用者就連不到服務
• 流量暴增時，一個 Pod 撐不住
• 維護或更新 Pod 的時候，服務會被中斷

難道我們要手動開一堆 Pod 來解決嗎？當然不是！今天就來看看 Kubernetes 怎麼透過 ReplicaSet 幫我們自動管理 Pod 副本，確保我們的應用程式不會因為單一 Pod 故障而中斷服務。

Replication Controller

在正式進入 ReplicaSet 之前，先認識一下它的前輩 —— Replication Controller (RC)。

它的任務就是維持指定數量的 Pod 在執行中。假設我們只有一個 Pod 在跑應用程式，如果 Pod 掛掉了，使用者就無法連線。但有了 RC，它會在偵測到 Pod 掛掉時，自動再幫我們建立一個新的 Pod。

所以大家常聽到 「Kubernetes 的 Pod 有自我修復能力」 ，其實背後就是 RC（或後來的 ReplicaSet）在幫你做這件事。這就是 RC 所帶來的 高可用性 (High Availability)。

除了 高可用性 (High Availability)，Replication Controller 還帶來兩個好處：

• 水平擴展 (Horizontal Scaling)：使用者變多時，會建立更多的 Pod 分攤負載，然後再由前面提過的 kube-proxy 來流量分配到不同的 Pod。
• 分散部署 (Spread across Nodes)：Pod 不會都塞在同一台 Node 上，減少單點故障的風險。

ReplicaSet vs Replication Controller

接下來來看 Replication Controller 的進化版：ReplicaSet (RS)。

簡單來說：

• ReplicaSet = 升級版 RC，主要功能一樣，都是確保指定數量的 Pod 副本數量。
• 差別在 selector 的彈性：
  • RC 的 selector 很陽春，只能做單純的 key-value 相等比對。
  • RS 的 selector 支援更進階的表達方式（In、NotIn、Exists），能應對更複雜的場景。

來看幾個例子（假設一個電商後端有多個服務）：

1. 基礎選擇 (RC 與 RS 都能做)

目標： api-service 只接穩定版 v1 API。

# RC
selector:   
  app: api   
  version: v1  
  
# RS 
selector:   
  matchLabels:     
    app: api     
    version: v1

2. operator: In — RC 做不到

目標： A/B 測試，需要同時導向 v1 和 v2-canary。

# RS only
selector:
  matchExpressions:
    - {key: version, operator: In, values: [v1, v2-canary]}

RC 沒有 In 的概念，只能拆成兩個 RC，管理上很麻煩。

3. operator: NotIn — RC 做不到

目標： 日誌系統要收集除了 payment-service 以外的所有 Pod。

# RS only
selector:
  matchExpressions:
    - {key: app, operator: NotIn, values: [payment]}

RC 沒有「排除」的能力，只能寫死所有要納管的 Pod。

4. operator: Exists — RC 做不到

目標： 監控所有有 critical 標籤的服務（不管值是什麼）。

# RS only
selector:
  matchExpressions:
    - {key: critical, operator: Exists}

RC 一定要 key+value 都指定，沒有 Exists (只要有這個標籤) 這種用法。

小結

• RC 和 RS 的主要功能相同，都是確保 Pod 副本數量正確。
• RS 是 RC 的加強版，支援更靈活的 selector，用來應對真實場景的複雜需求。
• 在現在的 Kubernetes 生態系裡，ReplicaSet 幾乎已經全面取代 RC。

ReplicaSet 實戰

YAML 聲明式宣告部署

來看看 ReplicaSet 的 YAML。整體結構跟 Pod 很像，只是多了兩個關鍵設定：

1. replicas：要幾個副本。
2. selector：要管理哪些 Pod。

而 template 部分，就是之前寫 Pod 的內容，直接搬進來即可。

ReplicaSet 的 YAML 檔結構跟 Pod 很像，但有幾個重要差異。從上面影片可以看到：

1. apiVersion 不同：ReplicaSet 用的是 apps/v1
2. spec 多了三個關鍵欄位：
   • replicas：指定副本數量，這裡 replicas: 3 表示我們要同時維持三個 Pod。
   • selector：定義要管理哪些 Pod，負責綁定 Pod 與 ReplicaSet 的關係。
   • template：Pod 的模板定義，原本 Pod 的配置。

特別要注意 template 部分，因為 ReplicaSet 是幫 Pod 建立副本，所以這裡的結構就跟我們之前建立 Pod 時一模一樣，只是把 Pod 的 metadata 和 spec 搬到 template 底下。

# replicaset-def.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  replicas: 3
  selector:
    matchLabels:
      type: front-end
  template:
    metadata:
	  labels:
		app: my-app
	    type: front-end
	spec:
	  containers:
	  - name: nginx-container
	    image: nginx

部署後可以看到 ReplicaSet 按照 YAML 檔的設定，維持 3 個 Pod 副本：

自我修復能力

接下來來測試當我們的 Pod 出現問題的話，ReplicaSet 是如何幫助我們解決這個問題的。下面影片左邊是指令輸入，右邊用 watch 指令即時監控 ReplicaSet 狀態，注意紅色框框內的關鍵訊息：

可以看到：

1. 一開始建立 ReplicaSet 時，Pod 從無到有，最後變成 Ready 狀態
2. 當我刪除 Pod 時，右邊的 Ready 數量從 1 變成 0，然後很快又變回 1
3. 這個過程中 ReplicaSet 自動幫我們重新建立了新的 Pod，這就是 ReplicaSet 的自我修復能力。

從下面截圖可以證實，Pod 刪除前後的名稱不一樣，代表 ReplicaSet 確實在 Pod 被刪除後，建立了一個全新的 Pod：

變更副本數量

如果想要調整副本數量，有兩種方式：

• 命令式（快速但不推薦）

kubectl scale replicaset.apps myapp-replicaset --replicas=5

• 聲明式（推薦）直接編輯 ReplicaSet 的設定：

kubectl edit replicasets.apps myapp-replicaset

修改 replicas 數值後儲存，Kubernetes 就會自動調整 Pod 數量。

總結

今天我們看到了 ReplicaSet 如何自動維持 Pod 的數量，帶來 高可用性 與 自我修復能力。
它比起 RC 更靈活，但角色上依舊單純 專注在維持 Pod 的副本數。

然而，光有 ReplicaSet 還不夠。 如果我們想要做到 應用程式的版本更新、Rolling Update (滾動部署)、Rollback (版本回滾) 等更進階的需求就力不從心了。

👉 所以明天，我們要認識更強大的控制器 —— Deployment。它建立在 ReplicaSet 之上，不只能管理 Pod 副本，還提供了完整的應用程式生命週期管理功能。可以說 Deployment 是 ReplicaSet 的上級管理者。

下一篇文章：應用更新不中斷？Deployment 滾動部署實戰